home *** CD-ROM | disk | FTP | other *** search
/ Collection of Internet / Collection of Internet.iso / infosrvr / dev / www_talk.930 / 000483_timbl@www3.cern.ch _Fri Dec 11 15:10:57 1992.msg < prev    next >
Internet Message Format  |  1994-01-24  |  3KB
  1. Return-Path: <timbl@www3.cern.ch>
  2. Received: from dxmint.cern.ch by  nxoc01.cern.ch  (NeXT-1.0 (From Sendmail 5.52)/NeXT-2.0)
  3.     id AA11752; Fri, 11 Dec 92 15:10:57 MET
  4. Received: by dxmint.cern.ch (5.65/DEC-Ultrix/4.3)
  5.     id AA07313; Fri, 11 Dec 1992 15:24:24 +0100
  6. Received: by www3.cern.ch (NX5.67c/NX3.0S)
  7.     id AA02698; Fri, 11 Dec 92 15:18:01 +0100
  8. Date: Fri, 11 Dec 92 15:18:01 +0100
  9. From: Tim Berners-Lee <timbl@www3.cern.ch>
  10. Message-Id: <9212111418.AA02698@www3.cern.ch>
  11. Received: by NeXT.Mailer (1.87.1)
  12. Received: by NeXT Mailer (1.87.1)
  13. To: Guido.van.Rossum@cwi.nl
  14. Subject: Re: Gopher+ Considered Harmful 
  15. Cc: www-talk@nxoc01.cern.ch
  16. Reply-To: timbl@nxoc01.cern.ch
  17.  
  18.  
  19. >  And I still don't.  I have the feeling that it would be much easier to
  20. >  adapt HTTP to other (non-TCP) transport protocols if the size of an
  21. >  entity is given separately rather than computed from the entity itself
  22. >  (after all this nonsense is only necessary because TCP doesn't have a
  23. >  way to distinguish EOF from a broken connection).  As I understand it
  24. >  your main objection is that under my proposal you will have to
  25. >  construct the necessary headers in a buffer first.  I don't believe
  26. >  that this is that much of a hassle in today's computers -- it
  27. >  shouldn't be more than a couple of kilobytes even in extreme cases,
  28. >  which is peanuts even for a standard PC.
  29.  
  30. It is not the space to buffer the stuff in the average case which is a problem.
  31.  
  32. There are extreme cases: Long documents which spew out of format converters
  33. piped into other format converters.  These things wouyld blow the memory of a  
  34. server which we never like to do.
  35.  
  36. There is the cumulative effect of response times.  Curerntly, almost all the W3  
  37. code is pipelines, so the reponse (click mouse to first character on screen) is  
  38. a function of the round trip delays and any real retrieval time. The moment you  
  39. put a buffer in to count bytes, you have to wait for the first until the last  
  40. is available. In the (frequent) case of many stages being involved in a  
  41. pipeline the response time does not in fact increase much, you just get a lot  
  42. of CPU from processors on the pipe line.  Once you buffer it up, you are using  
  43. CPU from one processor at a time.   You can't start displaying it until you've  
  44. parsed it and you can't parse it until you've read it and you can't read it  
  45. until the server has counted it and he can't even start to count it until all  
  46. the real work has been finished.
  47.  
  48. You will notice the difference immediately. 
  49.  
  50.  
  51. Piping things until EOF is so much faster.  Can TCP really not tell the  
  52. difference between a remote connection close, and a broken connection? :-((
  53. (APIs apart)
  54.  
  55. >  An issue on which I don't have a strong opinion is whether we should
  56. >  represent line separators as CRLF in the header -- anyone else?
  57. >  
  58.  
  59.  
  60. If you are going to be telnet-style, then CRLF it has to be.
  61. My comment in the proposed spec
  62.  
  63.     http://info.cern.ch/hypertext/WWW/Protocols/HTTP/HTTP2.html
  64.     
  65. was "...In particular, lines should be regarded as terminated by the Line Feed,  
  66. and the preceeding Carriage Return character ignored." under a note on  
  67. "tolerance".
  68.  
  69. Tim